Streaming server technology originally did not provide information about the available network bandwidth between servers and clients. Consequently, most servers often assumed that the bandwidth needed to stream content (e.g., movies) was available, and therefore sent Realtime Transport Protocol (“RTP”) packets to clients at the data rate of the content. If the actual bandwidth was less than that required, the RTP packets that did not fit into the network pipe would be discarded or lost. In addition, prior streaming technology often did not have error detection or correction available in the transport protocol (UDP) that was used to transmit RTP packets.
More recent streaming technology provides more reliable transmission of RTP packets using the same UDP transport protocol. In this technology, the client performs error detection and sends acknowledgements for the RTP packets it received from the server. The server, in turn, considers packets that are not acknowledged as lost on the network, and retransmits unacknowledged packets, which facilitates error correction.
This current streaming technology allows the server to calculate approximate available bandwidth as time progresses. The server uses this information to decide whether to throttle the stream bandwidth or increase it. However, with this technology, it is not possible to determine the available network bandwidth at the start of the stream.
If a client connects to a stream that requires more bandwidth than available, the server is not able to intelligently stream the content so that it fits the network pipe. By the same token, if the client has excess bandwidth, the server is unable to take advantage of the additional bandwidth to stream the content faster, or over-buffer the RTP packets. Since it does not know the ratio of available bandwidth to the required bandwidth, it is unable to determine the over-buffer rate at the start of the content.
Both current and past technologies do not aid the server in sending the most optimum stream to the client. Current technology, which includes reliable UDP and over-buffering, provides considerably better control over the stream as it is able to detect lost packets and retransmit them. Yet, using this technology does not solve several problems. For instance, when a client connects to a movie stream that requires higher bandwidth than what is available, the server will try to stream the movie at its authored data rate. Since the data rate is greater than the available bandwidth, the resulting movie would have poor quality.
Also, clients cannot report the bandwidth based on network settings as the available bandwidth spans a wide range for broadband connections. For example, clients on DSL connections may have a bandwidth ranging anywhere from 300 kbps to 1.5 Mbps. In this case, unless the bandwidth is determined at the start of the stream, the client may access a stream that requires much more bandwidth than available. Alternatively, the client may access a stream that requires only a fraction of the available bandwidth but the server will not know this early enough in order to determine the over-buffer rate of the stream. Therefore, there is a need in the art for a method that can dynamically determine the network bandwidth between the server and the client at a start of a streaming session.